x265编码的过程
x265编码的过程大概可以分为将输入文件decoding -> rescale -> encoding的过程。因为x265编码的复杂度，所以对硬件的压力很大，编码速度比x264要慢很多。 x265 encoding的流派大致分为显卡硬件编码和cpu的软件编码。
- 以N家为代表的显卡硬件编码的目标市场是直播， 实时的串流编码，所以其优化的方向是保证高fps的前提下，保证画质，文件大小并不是其关注对象，尽管可以设置crf来保证画质，但码率感人，不是适合收藏需要的高压缩场合。也不用花时间研究显卡硬编码了，因为它优化的重心就不是压缩率
- 基于cpu的软编码则是一般压片用的通用解决方案，但是速度感人。常用的preset大概就是medium, slow, slower。 slower是压制组的常用推荐，但是fps常在1左右摇摆，除非你有超多核的工作站，否则对简单的自用转码并不是适合，能效收益比很低。medium和slow基本就是自用转码可用的preset。medium的速度大概是slow的2倍以上，虽然质量不如slow，但可以通过调整crf的值来逼近slow，只是牺牲一点码率，是性价比很高的选择。
x265的编码软件选择ffmpeg就可，一行命令搞定。以前还有先用ffmpeg piping到x265来编码的说法 （因为旧版ffmpeg只有8bit x265的选择）。新版的ffmpeg整合的x265版本很新，且可选8bit+10bit+12bit。所以现在整个编码全在ffmpeg完成即可。
下面是我用的ffmpeg编码设定
@echo off
cd/d "%~dp0"
call :a %*
goto :end
:a
if "%~1"=="" goto :eof
ffmpeg.exe -vsync 0 -hwaccel nvdec -i "%~1" -vf scale=-1:1080 -pix_fmt yuv420p10le -c:v libx265 -crf 20 -preset slow -x265-params strong-intra-smoothing=0:rect=0:aq-mode=1:no-sao=1:limit-refs=3:no-amp=1:rd=4:ctu=32:ref=5:bframes=8:keyint=700:aq-strength=1 -c:a libopus -af aformat=channel_layouts="7.1|5.1|stereo" -b:a 256k "%~dpn1_Temp.mkv"
rem slow slower
rem bframes 4 8
rem rc-lookahead 25 40
rem lookahead-slices 4 1
rem ref 4 5
rem limit-refs 3 1
rem subme 3 4
rem amp 0 1
rem max-merge 3 4
rem recursion-skip 1 0
rem b-intra 0 1
rem weightb 0 1
rem rdLevel 4 6
rem tu-intra 1 3
rem tu-inter 1 3
rem limit-tu 0 4
shift&goto :a
:end
pause
关键的就是
ffmpeg.exe -vsync 0 -hwaccel nvdec -i "%~1" -vf scale=-1:1080 -pix_fmt yuv420p10le -c:v libx265 -crf 20 -preset slow -x265-params strong-intra-smoothing=0:rect=0:aq-mode=1:no-sao=1:limit-refs=3:no-amp=1:rd=4:ctu=32:ref=5:bframes=8:keyint=700:aq-strength=1 -c:a libopus -af aformat=channel_layouts="7.1|5.1|stereo" -b:a 256k "%~dpn1_Temp.mkv"
-vsync 0 表示同步输入的fps。
-hwaccel nvdec 代表用N卡解码。N卡的编码虽然拉跨，但是解码是没任何问题的，把解码的工作offload到GPU上可以减轻cpu的负担，改善编码速度。输入的文件标准越高，提速越明显，比如4K x265编码的文件。我的rtx2070s max-q硬解的时候GPU占用率只有区区的个位数。
-vf scale=-1:1080 代表的是rescale，这是将解码的视频流rescale到目标分辨率，scale用的是ffmpeg内置的算法，所以还是由cpu完成的。N卡也有硬件rescale的支持，rescale_npp或rescale_cuda，但需要ffmpeg编译时支持这个选项，现有的编译版本都没有支持，所以基本不可用，除非你自己安装N的SDK库编译。 -1：1080指设定y轴分辨率为1080，等比例的缩放分辨率。
-pix_fmt yuv420p10le 设定x265编码器为10bit， 8bit编码则是yuv420p。
-crf 20 -preset slow 就是最基本的控制速度和质量的参数，追求速度就将preset设为medium，crf减2即可。
-x265-params 是额外的x265编码选项，一般不需要碰，使用preset的预设值就好，这里是抄了有些压制组的作业，比较重要的就是no-sao和no-amp， sao和amp以前一般认为对质量是负优化还降低速度，以前是建议关闭的，现在不知道状况。
-c:a libopus ...是音频编码，一般不用改了。
10bit编码比8bit编码慢，但是基于ssim, psnr, vmaf看，质量要高。用10bit,medium的组合可以逼近8bit，slow的组合，速度上medium比slow快太多了。10bit是性价比很高的选择。
综合下来，追求速度就选10bit+medium+crf-2，追求码率就10bit+slow+crf。
压制组实验出来的参数都是基于输入是高质量的视频，x265的码率比x264有优势。如果只是想将x264转为x265其实没什么必要，压制的过程是将输入解码，resale，再编码。如果输入已经是x264中低码率压制过了，其实再压的意义不大，虽然可以减小体积，但质量会进一步降低 （经过两次有损压缩）。还不如多买块硬盘完事。自用的压缩只有是输入是蓝光（x264高码率）或是4K降低分辨率才值得费这个力。